Learning Objectives

After completing this lesson, you'll be able to:

• Create a dynamic workspace with multiple readers.
• Add a Resource Reader.
• Change the source of a dynamic workspace schema.
• Add and remove hard-coded attributes in a dynamic workspace.

Resources

• Complete workspace
  • If your computer has FMEData, the file path is C:\FMEData\Workspaces\AdvancedReadingAndWriting\exercise-define-schema-from-an-external-source-complete.fmw
    
• FireHalls.gml
  • C:\FMEData\Data\Emergency\FireHalls.gml

Introduction

In previous exercises, you worked with the community mapping dataset, which the planning department uses for various community mapping tasks.

However, as time has passed, this dataset has become outdated. The planning department, therefore, wants to start building a new community mapping dataset. The dataset will have new data but use the existing schema where possible. They also – to use an open standard – want a format change to GML.

The department has identified two source datasets as required in the new community mapping "database." They are fire halls (source format: GML) and city parks (source format: MapInfo TAB). There was already parks data in the community map, but this new dataset consists of polygon geometry, not point. The fire halls data is entirely new for the community map.

So, let's create a new workspace to generate this new dataset.

1) Start Workbench

Start by generating a workspace as follows:

We chose the dynamic option so we can define our writer schema using a different dataset than the one we are reading.

2) Add Reader

So far, so good. Now let's add a reader for the new parks data by selecting Readers > Add Reader and using the following details:

Connect the new reader feature type up to the existing writer feature type, and add an annotation for the reader feature types for easier recognition:

Ensure caching is on and run the workspace. This step will load up the source dataset caches. Inspect the two source datasets in Visual Preview to become familiar with them.

3) Add Resource Reader

One of the requirements is to use the existing community mapping schema where possible. With the fire halls, this isn't possible since that data never existed in the original CommunityMapping Geodatabase. However, the parks dataset did exist in that Geodatabase, so we'll need to use that schema.

So, select Readers > Add Reader as Resource and, when prompted, enter the following details:

Click OK, and the Navigator shows the reader as a Resource:

4) Adjust Dynamic Parameters

Now we need to ensure that the writer feature type uses the resource schema.

Inspect the properties for the writer feature type. Click the Schema Sources browse button. Put a checkmark against CommunityMap. Ensure you have not checked Parks but have checked FireHalls:

Inspect the other dynamic parameters. Since we are writing both points and polygons, we might have to change a Geometry setting for some formats. But since GML can cope with both geometry types, we won't have to take any action; there will not even be a parameter for geometry type! Accept the parameter changes to close the dialog.

5) Save and Run Workspace

Save the workspace and then use Run > Rerun Entire Workspace.

Inspect the output. There should be two layers: one for fire halls and the other for parks. The parks dataset should have the schema from the CommunityMapping Geodatabase (not the MapInfo TAB Parks dataset), including attributes for ParkName, ParkAddress, and ParkURL (even if there is no data to fill some fields yet):

Notice that it also has OBJECTID, which came from the Geodatabase, and we don't need it.

6) Delete Attribute

Revisit the writer feature type parameters. Click the button for Attributes to Remove and type OBJECTID into the first row of the dialog that opens. You won't be able to select it from the drop-down list because it comes from a resource reader, not a real reader:

Click OK to close this dialog, but don't close the feature type dialog yet.

7) Add Attribute

A last-minute request is to add an attribute – LastUpdatedBy – to all tables in the output.

So, click on the User Attributes tab and add this new attribute. Make it a 30-character string.

As you can see, there is no need to change the attribute definition mode - it should stay as dynamic.

9) Rerun Workspace

Save the workspace and rerun it.

Inspect the output. Notice that OBJECTID will not appear as an attribute. LastUpdatedBy does appear - on both Parks and Firehalls - albeit that it doesn't have a value yet. We'll fix that problem in a later exercise.